1. Field of the Invention
The present invention generally relates to computer systems and object-oriented programming languages. More particularly, the present invention relates to the design and use of persistent configurable Java classes that have attributes and methods that are alterable during run-time of the system without requiring the removal and redeployment of the classes.
2. Description of the Related Art
In volatile industries, where standards are being formed, such as in the world of business to business (B2B) systems, developers need to be able to adjust applications rapidly. This includes making changes to the implemented business processes and the data these processes work with. In an object-oriented environment, this leads to the requirement of being able to define new classes (behavior and state) and to change existing classes within the application, without disrupting any of the existing functionality, and without having to xe2x80x9credeployxe2x80x9d the application into its target environment. For example, if an existing application with a business-to-business (B2B) interface needs to react to evolving data exchange format standards rapidly, new definitions of that standard lead to new and changed behavior and state within the existing application.
In a business computer environment, Enterprise JavaBeans (EJB) is a common server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE). EJB is a specification that defines a standard architecture for implementing the business logic of multi-tier applications as reusable components. In addition to EJB components, the EJB architecture has servers, containers, and clients.
There are three categories of EJB methods: home interface methods, business logic methods, and container interaction methods. Home interface methods correspond to methods in the bean""s home interface, and such methods are largely for creating, locating and accessing instances of the bean. Business logic methods are methods provided by the bean""s remote interface to facilitate the functionality of the bean in its intended business environment. Container interaction methods are methods for interacting with the container and are not intended for client access. Consequently, the container access methods are hidden by the container.
There are two types of enterprise beans: session beans and entity beans, and each type of bean represents a different level of business logic abstraction. Session beans represent behavior associated with client sessions generally implemented to perform a sequence of tasks within the context of a transaction. A session bean runs processes on behalf of the client remotely on the server as a logical extension of the client program. Entity beans represent specific data or collections of data, such as a row in a relational database. Entity bean methods provide operations for acting on the data represented by the bean. An entity bean is persistent and survives as long as its data remains in the database.
A client accesses an Enterprise JavaBean by looking up the instance of the class implementing its home interface by name. The client then uses methods of the home interface to acquire access to an instance of the class implementing the remote interface. In addition to generating classes to implement both the home and remote interface, the container is responsible for binding the home class using a name server, which it communicates with via the standard JNDI API. Such function is generally handled automatically by the container tools at deployment time.
A container provides Enterprise Java Beans components with services of several types. First, the container provides services for lifecycle management and instance pooling, including creation, activation, passivation, and destruction. Second, the container intercedes between client calls on the remote interface and the corresponding methods in a bean to enforce transaction and security constraints. The container can provide notification at the start and end of each transaction involving a bean instance. Finally, the container enforces policies and restrictions on bean instances, such as reentrance rules, security policies, and others.
The tools for a container generate additional classes for a session bean at deployment time. These tools get information from the EJB architecture at deployment time based upon the EJB""s deployment descriptor or by introspecting the architecture classes and interfaces. The tools use this information to dynamically generate two classes to implement the home and remote interfaces of the bean. The interface classes enable the container to intercede in all client calls on the session bean. The container also generates a serializable xe2x80x9cHandlexe2x80x9d class, providing a way to identify a session bean instance within a specific life cycle. Such classes can be implemented to mix in container-specific code for performing customized operations and functionality. In addition to custom classes, each container provides a class to provide metadata to the client and implements the SessionContext interface to provide access to information about the environment in which a bean is invoked.
Session beans are not persistent, whether stateful or stateless. The data maintained by a stateful session bean is transitional, and solely for the purposes of a particular session with a particular client. A stateful session bean instance does not survive system failures and other destructive events. While a session bean has a container-provided identity (the xe2x80x9chandlexe2x80x9d), that identity passes when the session bean is removed by the client at the end of a session. If a client needs to revive a stateful session bean that has disappeared, it must provide its own means to reconstruct the disappeared bean""s state. The entity bean developer defines the home and remote interfaces that represent the client view of the bean. Entity bean developers also create a class that implements the EntityBean interface, as well as methods corresponding to the methods in that bean""s home and remote interfaces. In addition to defining methods in the EJB Home interface, the entity bean developer also implements finder methods.
A xe2x80x9cfinderxe2x80x9d method provides a way to access an entity bean through the bean""s contents. Finder methods are designed to be introspected and displayed by development and deployment tools, which enables a user to graphically manipulate entity beans in the process of developing applications. The principal finder method that must be implemented by all entity beans is xe2x80x9cfindByPrimaryKey.xe2x80x9d In addition to this method, the developer can implement a xe2x80x9cPrimaryKeyxe2x80x9d class to provide each entity bean with a unique, serializable identity, and in accord with the EJB 1.1 specification, any base type attribute of the EJB can be declared to be the primary key.
As with session beans, the tools for a container generate additional classes for an entity bean at deployment time to implement the home and remote interfaces. The additional classes enable the container to intercede in all client calls on the same entity bean. The container also generates the serializable Handle class to providing a method to identify the entity bean within a specific life cycle. The additional classes can be implemented to mix in container-specific code for performing customized operations and functionality. Each container provides a class to provide metadata to the client. And a container also manages persistence of selected fields of the entity bean where specified by a particular bean.
A container supports the following values for the transaction attribute of an Enterprise JavaBean:
xe2x80x9cNot Supportedxe2x80x9dxe2x80x94The bean runs outside the context of a transaction, and existing transactions are suspended for the duration of method calls.
xe2x80x9cRequiredxe2x80x9dxe2x80x94This method call requires a transaction context, so if one exists, it will be used, and if none exists, a transaction context will be created.
xe2x80x9cSupportsxe2x80x9dxe2x80x94This method call uses the current transaction context if one exists, and will not create a transaction context if none exists.
xe2x80x9cRequires Newxe2x80x9dxe2x80x94Containers create new transactions before each method call on the bean, and commit transactions before returning.
xe2x80x9cMandatoryxe2x80x9dxe2x80x94This method call requires a transaction context, and if none exists an exception is thrown.
xe2x80x9cNeverxe2x80x9dxe2x80x94This method call requires that no transaction context be present. If one exists, an exception is thrown.
Only session beans can start their own transactions; in other words, bean-managed transactions are not supported for Entity beans and the container suspends any current transaction in the client context. Thus, in the bean""s method implementation, the bean initiates the transaction through the UserTransaction interface. In stateful beans, the container associates the bean instance with the same transaction context across subsequent method calls until the bean explicitly completes the transaction. However, stateless beans are not allowed to maintain transaction context across method calls. Each method invocation must complete any transaction that method initiates.
In regard to persistence of the data of entity beans, there are two types of persistence: container-managed and bean-managed. In container-managed persistence, entity bean data is automatically maintained by the container using one of several methods. For example, a container implemented on top of a relational database management system (RDBMS) may manage persistence by storing each bean""s data as a row in a table. Otherwise, the container can use Java programming language serialization for persistence. When a bean""s persistence is container managed, the bean specifies which of bean""s fields are to be retained. In bean-managed persistence, the bean is entirely responsible for storing and retrieving that bean""s instance data. The EntityBean interface provides methods for the container to notify an instance when the EntityBean needs to store or retrieve its data.
In an EJB environment, changes can typically only be made by manually changing code and xe2x80x9credeployingxe2x80x9d the EJB. The changes involve the generation of a number of supporting classes that are specific to the target EJB server. Thus, the common method to replace a business class requires taking down and restarting the entire server environment so that the new classes can be loaded.
It would therefore be advantageous to provide a system and method for making changes in a J2EE environment, such as added new class or altering existing classes, at runtime of the system with minimal interruption. In such system and method, new functionality could be introduced without needing to redeploy the entire application, and without further manual coding and compiling of the system software. It is thus to the provision of such a system and method for defining, configuring and using dynamic, persistent Java classes that the present invention is primarily directed.
Briefly described, the present invention is a system, method, and computer program for the creation and implementation of configurable Java classes on a computer platform executing instructions based upon at least a set of Java language instructions. The configurable Java class is created as an instance of a metaclass object included within the set of Java language instructions, and the configurable metaclass object includes a plurality of subclasses and interfaces wherein each interface includes one or more methods to alter the attributes and methods of the Java class instance of the metaclass object. The system includes a computer platform executing instructions based upon at least a set of Java language instructions, and a configurable metaclass object is included within the set of Java language instructions. The plurality of subclasses and interfaces of the metaclass object include methods to selectively alter the attributes and methods of a Java class instance of the metaclass object without having to redeploy the system or recode the Java class. The metaclass object thus allows the reconfiguration of a configured Java class with dynamic and configured methods through one or more of the interfaces.
The present invention is preferably implemented on a J2EE platform, and therefore, the class instances of the metaclass object are preferably implemented as persistent entity Enterprise JavaBeans. The plurality of interfaces is preferably comprised of a dynamic entity interface that includes a method container interface and a property container interface, and the dynamic entity interface includes the methods for altering the Java class instances of the metaclass object. The method container interface and property container interface are read-only interfaces that allow the passing of immutable objects. The metaclass object can be coded in XML, Java, or any other programming language with like functionality.
The invention also comprises a computer program embodied on a computer-readable medium, such volatile and permanent memory and secondary storage, and the program enables a configurable persistent Java class within a set of Java language instructions including a configurable metaclass object. Within the program, the class instances of the metaclass object are preferably implemented as a persistent entity Enterprise JavaBean. And the metaclass object further preferable contains a plurality of interfaces comprised of a dynamic entity interface including a method container interface and a property container interface. The dynamic entity interface includes the methods for altering the Java class instances of the metaclass object, and the method container interface and property container interface are read-only interfaces that allow the passing of immutable objects.
The invention further comprises a method for altering a configurable Java class on a computer platform that includes the steps of creating a Java class as an instance of a metaclass object, the configurable metaclass object allowing the reconfiguration of the configured Java class with dynamic and configured methods, and selectively altering the attributes and methods of the Java class through one or more of the instantiated metaclass object interfaces.
The step of creating the Java class instances of the metaclass object is creating the Java class as a persistent entity Enterprise JavaBean. Further, the step of selectively altering the attributes and methods of the Java class is preferably altering the Java class through a dynamic entity interface including a method container interface and a property container interface, wherein the dynamic entity interface the method container interface and property container interface allow the passing of immutable objects.
The present invention thus allows the creation of new Java classes and the change of existing Java classes through persistent configuration, which can occur at run-time of the system without interruption of the system. New functionality can be introduced by configuring new classes rather than redevelopment and redeployment of the java classes, and includes reconfiguring both behavior and state of the class. As the created and changed Java classes are preferably implemented as Enterprise JavaBeans, the objects are available in a distributed, transactional environment. With the creation of configurable Java classes as an EJB environment, changes can be made without manually changing code and xe2x80x9credeployingxe2x80x9d the Enterprise JavaBean.